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A System and Method for Navigating Patient Medical Information 

Cross %g.fe,Tmct to H^cCatecCJlppCications 
This application claims the benefit of provisional U.S. application, U.S. Serial 
No. 60/248,086 filed November 13, 2000. 

^ie-tdof the. Invention 

This invention is related to the processing and displaying of medical 
information, and more particularly to processing and displaying of patient medical 
data associated with groupings of patients in a network environment. 

'Background- of tfie Invention 

In hospitals and other health care environments, it is often necessary or 
desirable to collect and display a variety of medical data associated with a patient. 
Such information may include laboratory test results, care unit data, diagnosis and 
treatment procedures, ventilator information, attending physician or health care 
provider, and administrative or admission related information associated with a given 
patient. 

Presently, such information is often provided via a chart attached to a patient's 
bedside or at an attendant's station. However, such physical charts are cumbersome 
to view, and often do not include the most up-to-date medical information associated 
with the patient. This problem is exacerbated due to the fact that such medical data 
arrives from multiple sources and at various times. Furthermore, present charts are 
not adapted to enable a physician or other care giver to easily access, view, or 
determine the results of multiple medical tests or other data associated with the 
patient. In addition, present techniques for navigating through a variety of patients' 
medical information are both tedious and inefficient, requiring extensive manual 
review and manipulation of physical chart information, or numerous selections via a 
user interface screen if information is available in electronic format. Moreover, 
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tracking patients through multiple care units (e.g. from ER to CCU to ICU) presents a 
formidable problem using present techniques. Consequently, a need exists for a 
faster, more effective and user friendly means for navigating patient medical data 
associated with groupings of patients in a network environment including accessing, 
correlating, tracking and displaying patient medical information derived from a 
plurality of sources. 



Summary oftfk Indention 

A network compatible user interface system and method are presented for 
supporting navigation through patient medical information. The system comprises a 
communication processor for acquiring a patient group identifier allocated to a 
grouping of patients and for acquiring medical information associated with the 
patients. A display generator operates to generate a composite display window 
incorporating a first window including the patient group identifier and a list of 
patients in the grouping and a second window for displaying different medical 
information corresponding to different medical applications. The different medical 
information is associated with patients within the patient grouping. A display 
navigation processor maintains the first window display while displaying different 
medical information in the second window in response to user navigation between the 
different applications. 

In another aspect, the system of die present invention continuously 
acquires medical information associated with patients within the network. A patient 
relocation detector detects a relocation indicator contained in a message broadcast 
from a node on the network that indicates a patient has moved location in a care 
facility. This relocation indicator may be a flag set within the data base or on a name 
server uniquely identifying the patient with a new care facility and/or monitoring unit. 
A communication processor automatically acquires new information for the relocated 
patient in response to the relocation indication, wherein the new information 
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comprises a patient group identifier allocated to a grouping of patients including the 
relocated patient, and medical monitoring information for the relocated patient at the 
new location. 

In yet another aspect, the invention is embodied in a network 
compatible user interface system supporting navigation through patient medical 
information comprising a communication processor for acquiring patient medical 
information for storage in a data base and a menu generator for generating a menu 
prompting user selection of a field to be searched. A search engine searches the data 
base of acquired medical information to identify patients associated with search 
criteria determined by user selection of the field and entry of a text string. A display 
navigation processor automatically displays different medical information for the 
identified patients in response to user navigation between different applications. 

The medical information displayed is based on patient data for those patients 
presently associated with a particular group ID such as an intensive care unit or 
emergency room unit. This is advantageous for automatically providing the most 
current, updated patient information associated with a given care unit. Such 
information includes patient identifier information, ventilator information, diagnosis 
information, procedure information, caregiver responsibility, and laboratory test result 
indicators. 

'Brief 'Descnption of the, Draxvings 

In the drawings: 

Figure 1 is a block diagram of a communication network with various devices, 
according to the principles of the invention. 

Figure 2 represents a flow diagram of a process for searching and displaying 
patient information according to an aspect of the present invention. 
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Figures 3A - 3C are exemplary illustrations of ways for navigating through a 
listing of patients and patient records according to an aspect of the present invention. 

Figure 4 is an exemplary illustration of how admission results data are 
displayed according to an aspect present invention. 

Figure 5 shows an exemplary illustration of how patient information 
associated with a given care unit are displayed in board view mode according to an 
aspect of the present invention. 

Figure 6A represents a flow diagram for displaying application specific data 
while maintaining a list of grouped patients according to an aspect of the present 
invention. 

Figure 6B provides an exemplary illustration of the resultant screen display 

associated with the flow diagram of Figure 6A. 

Figure 7 represents a flow diagram for detecting, tracking and updating the 
location of a patient within the system according to another aspect of the present 
invention. 

Figures 8 A, 8B, 8C represent exemplary illustrations of search functions for 
retrieving and displaying patient information related to user-defined search criteria 
according to another aspect of the present invention. 

Figure 9 is a block diagram of a server having functionality in accordance 
with the present invention. 

'D&taiCed 'Description 
Figure 1 is an exemplary block diagram of a communication network 
according to the principles of the present invention. Throughout the document, like 
reference numerals are used to indicate like parts. As shown in Fig. 1, 
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communication network 1 is represented by an IP (Internet Protocol) compatible 
network with a hierarchy of local area and wide area networks interconnected 
together. It is to be noted that although the present exemplary hospital or medical 
network is an IP compatible network, other types of networks such as, but not limited 
to optical or wireless networks, using other computing protocols such as, but not 
limited to, for example, X.25, frame relay, IBM SNA etc., may also be used, as one 
skilled in the art can readily appreciate. In addition, although the exemplary network 
described is a hierarchical network, this is not required by the present invention. Any 
type of network architecture that provides communication connectivity among the 
devices on the network may be used. 

As shown on Fig. 1, the first level of the exemplary hierarchical network 1 
comprises a Medical Interface Bus (MIB) 2. A MIB is a well-known medical 
industry standard for locally connecting medical devices together. As shown in Fig. 
1, MIB 2 is typically used to interconnect medical devices in a patient's room to 
administer care to a particular patient and to monitor the particular patient. Various 
medical devices may be connected via MIB 2; examples shown in Fig. 1 comprise a 
ventilator 6a, IV (Intravenous) Pump 8 or other medical equipment 10. 

MIB 2 is typically connected to a second level LAN network 3 through an 
Interface Docking Station (IDS) device 12, for interfacing to Ethernet-compatible 
LAN network 3. The higher-level LAN 3 may be for example, an Infinity LAN, 
marketed by Siemens Medical System. This higher-level LAN 3 is typically, though 
not necessarily, used by a particular department within a hospital, such as an intensive 
care department or surgery department, etc., depending on the size of the 
organizations. 

Although not shown in Fig. 1, more than one MIB may be connected to the 
second level LAN 3, so that more than one patient may be monitored or given care 
through LAN 3. In addition, medical devices may be connected directly to higher- 
level LAN 3. For example, as shown in Fig. 1, a ventilator 6b and an anesthesia 
system 13 are connected directiy to LAN 3, without the need to go through a MIB. 
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Furthermore, LAN 3 may be interconnected to a Hospital LAN backbone 4 
which also is Ethernet compatible. This backbone network 4 provides 
communication connectivity between various departments within a hospital or 
medical organization; for example, connecting hospital administrative systems 15 
10 together with laboratory systems 17. In addition, the Hospital LAN 4 has a remote 
access gateway 19 which provides remote, secured access from, for example, a 
remote doctor's office 23 or a remote care site 24, to the various systems and devices 
on network 1, through for example, Internet 29. Alternatively, a remote site may also 
1^ access the remote access gateway 19 direcdy through, for example, a dial-up 

P 15 telephone port, ADSL, or other types of private connection. Remote access gateway 
^ 19 may also be part of server 20, to be described below, instead of standing alone, as 

^ well know in the art. 

n: 

According to the principles of the present invention, a central server 20 resides 
20 on LAN 3 for gathering and processing data from the peripheral medical devices or 
l_ facilities coupled to LAN 3 or hospital LAN 4, including medical parameters such as 

lab results supplied via lab system 17 connected through an HL7 interface, for 
N example. Additional medical parameter data including cardiology, hemodynamic, 

ventilation and neurology category data may also be acquired from any number of 
25 medical devices such as those shown in Figure 1 and may be obtained at server 20 
using various interface protocols including HL7 or ASTM messaging, for example. 
The acquired medical parameters associated with a given patient, including laboratory 
test results, are acquired from the medical devices on network 1 for display and 
control. One skilled in the art can readily recognize that server 20 may reside at any 
30 level of the hierarchy of network 1, since all the different levels of LANs (e.g., 3, or 
4), as well as remote sites in Fig. 1 are interconnected together. An example of server 
20, is a ChartAssist™ server, marketed by Siemens Medical System. The server may 
be hosted, for example, by a computer system that is capable of running Microsoft NT 
operating system. 



35 
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Fig. 2 shows in flow chart form, functions that may be performed by server 20 
in conjunction with the user interface software resident on a web browser 27 of a 
client computer 26 configured to navigate between applications in accordance with 
the present invention. Server 20 first establishes communications with devices on the 
network as shown in step 202. This is done, for example, by using IP protocol and 
the known IP device address for each device on the network 1, in conjunction with 
any higher application-layer protocols, as well known in the art. 

Once communications are established between server 20 and the other 
devices, server 20 starts to acquire parameters that are being monitored and settings 
selected for the various devices. A communication processing module or software 
program operates to acquire the patient data including the monitored parameters and 
collate the information for storage in a data base. As previously mentioned, such 
parameter data may be obtained through an HL7 interface with LIS 17, or via ASTM 
or MIB point of care (POC) medical devices depicted in Figure 1. 

Medical parameter data including cardiology, lab results, hemodynamic, 
ventilation and neurology category data may be continuously or periodically acquired 
and correlated with a given patient for storage in relational data base 25 within server 
20. Data base 25 may be of the type used for storing relational data such as the 
Microsoft SQL server. The acquired data may include time stamp information or 
other information indicative of the date and time associated with the acquired data. 

Server 20 is therefore capable of collating and formatting medical data to be 
compatible with, for example, HTML (HyperText Mark-up Language) programming 
language for displaying data on a web browser having a graphical user interface 
(GUI) component. The server is also responsive to, for example, HTTP (HyperText 
Transfer Protocol) commands originated from a user's web browser for making a 
request. Figure 9 shows a block diagram of an exemplary embodiment of the server 
20 which operates to manage, collate, search and update the data base 25 (Figure 1) 
containing patient medical information. Program elements or processors operative to 
carry out instructions for performing the various functions described herein include 
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5 communications processing module 2502 (Figure 9) that acquires the patient data 
including the monitored parameters and group identifiers allocated to patient 
groupings and collates the information for storage in data base 25. Navigation 
processor 2504 operates in conjunction with the web browser and display generator 
software to maintain display parameters for display to the user while navigating 

10 through various applications selected by a user through the user interface. Name 
server processor 2506 associates unique identifiers (Ids) with each node connected to 
the system network and with each patient in the system in order to track and update 
patient information throughout the system. Input/output data and control signals are 
used to communicate between the various processors as well as to interface with the 

15 data base 25 and search engine 23 and with the network via communication line 2510. 

In one aspect of the present invention, a user may use a Microsoft Windows 
compatible PC 26 or Windows NT compatible PC 39 as shown in Fig. 1, or any other 
computers capable of running a menu generating program such as a web browser 
°" 20 program (e.g., Microsoft Internet Explorer or Netscape Navigator, etc.) to view the 
aforementioned category type medical data associated with a given patient. That is, a 
user may use a web browser on any computer, as long as a communication connection 
can be made to server 20, to make request and view information acquired and stored 
in data base 25. This is advantageous, since a doctor may for example, gain access to 

25 medical parameter data from, for example, a remote physician's office 23, without 
having to access a dedicated terminal. Of course, a user can simply use a keyboard 
and/or a mouse or any other user interface devices to enter a user selection or request 
on a user computer, as is known in the art. The user interface contains functionality 
for maintaining a displayed listing of patients within a group while navigating 

30 between different applications operative to retrieve and display different medical data 
associated with a selected patient within the group. Such functionality includes a 
browser containing a display generator module for displaying a composite window 
containing both patient listing data and medical data associated with a selected 
patient. A navigation processor software module responsive to user input operates to 

35 maintain the displayed patient listing data while displaying different medical 
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5 information in associated with the selected patient in response to user navigation 
between different applications. 

Figures 3A - 3C are exemplary illustrations of a user interface system 
embodied in an aspect of the present invention for providing a flexible means of 

10 navigating through a listing of patients and/or patient records stored in the system 
data base 25. The listing of patients may be those patients currently admitted to the 
hospital or health care unit, or may be those patients identified within the network that 
are not yet admitted. In accordance with the present invention, the navigation 
mechanism may be based on particular care units or other user specified search 

15 criteria. 

Referring now to Figure 3A, there is shown an exemplary embodiment 
of a user interface display 300 that enables a user to view, select and acquire patient 
information associated with a given care unit. Composite display 300 comprises a 

20 first window portion 310 for viewing and manipulating patient and care unit 
information, and a second window portion 320 for displaying different medical 
information corresponding to different medical applications. Care unit label 301 
comprises a display portion for displaying the current care unit and for providing a 
pull down list of all care units (e.g. 301A, 301B) monitored within the network for 

25 selection by the user. A search option 301c is also included within the selectable pull 
down menu via label 301 to provide a user-entered search of patient-related 
information. In an exemplary embodiment, a hospital may include a plurality of care 
units defined by category and organized within the relational data base to include one 
or more of an intensive care unit, critical care unit, maternity, gynecological or 

30 obstetrics care unit, emergency care unit, bum unit, neurological unit, surgical unit, 
pediatric or baby unit, infectious disease unit, and oncology unit. Note that a patient 
is typically assigned to a given care unit based on the particular medical needs of the 
patient relative to the type of care that each unit provides. In this manner, each 
patient may be allocated a group identifier (ID) associated with a particular care unit. 

35 It is of course, understood, that other group IDs may be used to associate certain 
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patient data records within the data base 25 in relational fashion as is well known in 
the art. 

Still referring to Figure 3A, in conjunction with the flow chart depicted 
in Figure 2, user selection (e.g. via mouse click) of the particular care unit causes a 
search of the data base 25 to display a listing 315 of the names of those patients 
associated with the selected care unit (or search string). The listing includes the 
patient name 315a, patient ID 315b, and bed label 315c, if applicable, for each 
patient. Formatting software operates to adapt the listing to the display screen. In the 
event the listing exceeds the space allocated for a given screen, a page selector 318 
located at the lower left hand comer of window 310 enables a user to quickly access 
particular pages of displayed patient information viewable on display 300. In a 
preferred embodiment, the patient list is displayed in alphabetical order by last name. 
However, it is understood that the list may be displayed in a variety of different sort 
orders, such as by bed number or patient ID, for example. 

User selection of the search option 30 IC from the selected care unit 
generates a pop-up entry panel 800 (see Figure 8A) to be displayed to the user, 
prompting the user to enter a search string. Entry of the user-selected search string 
causes the search engine 23 within database 25 to search and retrieve a listing of 
patients within the database having a searchable record within the data base 25 that 
matches the user-entered search string. 

A set of icons labeled generally as 319 positioned, for example, at the 
upper right hand comer of display 300 operates to provide quick access to basic 
functions associated with the system of the present invention. For example, user 
selection of admit icon 319a causes the user interface to generate display screen 400 
shown in Figure 4 which displays a list of all patients in the selected care unit (e.g. 
ecu) who are recognized within the network but who are not yet admitted to the 
system. That is, upon user selection of the admit mode of operation, a query -is 
executed on server 20 and the user interface panel displays a list 415 of all patients in 
the selected care unit (CCU) having database entries defining their entry or 
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connection within the communication network, but who are not yet admitted into the 
system. Subsequent selection of a given patient from the list of patients provides a 
link to an input screen for entering or updating relevant patient information including 
address data, physiological data, and admission date, as well as an input screen for 
entering physician and family contact information. 

The system of the present invention operates to maintain identification of the 
selected care unit 301 throughout each of the system modes selectable via the set of 
icons 319, namely admit mode 319a, board view mode 319b, and patient view mode 
319c. The system is operative in board view mode to provide a display containing 
certain medical information in a chart like format for each of the patients within the 
selected care unit. Patient view mode provides a display containing certain medical 
information associated a particular patient within the selected care unit. 

For example, upon user selection of the board view icon 319b, the user 
interface processor displays a list of all patients in the selected care unit 301 that are 
currently admitted to the system. An exemplary illustration of such a screen is shown 
in Figure 5 which identifies the care unit 301 and associated listing 315 of the 
patients, including patient name, patient ID, and bed number. Additional medical 
data is further included within the application window, including status 530, 
ventilator 540, diagnosis 550, procedure 560, lab results 570 and attendant area 
(MD/RN) 580. As previously mentioned, when the patient list exceeds the viewable 
page allocation, a page indicator 318 displays the number of pages in addition to the 
current page and provides a hyper link to the other pages. 

Status field 530 provides a free text field into which a user or operator 
can enter textual information. This may be accomplished by data entry through a 
keyboard, light pen or other manual input means. Ventilator field 540 displays the 
current mode of ventilation associated with a given patient as well as the number of 
hours that the patient has been continuously ventilated. The ventilator field values 
and parameter settings may be automatically acquired from ventilator units connected 
via the network or may be entered by a user. Diagnosis field 550 operates to display 
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5 the most recent primary and secondary diagnoses associated with each patient within 
the selected care unit, while procedure field 560 displays the most recent stored 
medical procedures for each patient. 

Note that, upon user selection of a given patient from the listing of 

10 patients (see Figure 3A or Figure 5), patient specific information is accessed and 
retrieved from the data base 25 and displayed to the user in first window portion 310. 
By way of example, selection of a given patient labeled at 3151 from the census panel 
display 300 shown in Figure 3A generates the display screen shown in Figure 3C 
wherein a first window portion displays patient summary information 3160 at the top 

15 of the screen. As shown in Figure 3C, the system of the present invention operates in 
a default mode to remove the list 315 of patients within the selected care unit upon 
selection of a particular patient from the list to enable a user to tab through various 
applications 3201 to view the particular patient's data. The summary information 
includes bed label 3162, patient name 3164, patient ID 3166, age, height and weight 

20 information 3168 and admission information 3169 such as the patient's admit date. 
Summary information display 3160 may further include an indicator 3170 if the 
patient is currently admitted to the system but is not currently active on the network. 
That is, if in response to a search request, the monitor or peripheral device to which a 
given patient had been connected to (via an associated node within the 

25 communication network) and who has been previously registered within the network 
is no longer responding, an indicator 3170 is displayed alerting the user to such 
detection. This may occur, for example, if a patient is removed from a ventilator unit, 
or may occur during transit from a given care unit (e.g. during transfer of a patient 
from an intensive care unit (ICU) to the operating room (OR)). 

30 

Navigation control processing is enabled by tabs labeled generally as 
3201 which provide access to various applications for display in second window area 
320. In the exemplary embodiment shown in Figure 3C, such application tabs may 
comprise Summary 3202, Vitals 3203, Notes 3204, Labs3205, Demographics3206, 
35 Ventilator 3207 and Report 3208 tabs for launching corresponding applications for 
retiieving information from the data base 25 in accordance with predetermined search 
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criteria. Each of the tabs 3201 may further include additional tab functions associated 
therewith to provide access to and processing of certain applications for display in 
window portion 320. 

As previously discussed with respect to Figure 3C, the system of the 
present invention in a default mode operates to remove the Figure 3 A list 315 of 
patients within the selected care unit upon selection of a particular patient from the 
list to enable a user to tab through various applications to view the particular patient's 
data. An advantageous feature of the present invention comprises selection icon 319d 
which operates, responsive to user selection of the icon, to maintain or "pin" the 
panel list 315 of patients within first window portion 310 even after a particular 
patient is selected. Pin icon 319d provides an indication to the user as to whether the 
list has been pinned (i.e. will be maintained for continued display). In an exemplary 
embodiment, such indication may be a visual indicator such as a different shape, font, 
or color attribute associated with pin indicator 319d. As shown in Figure 3A, Pin 
indicator 319d is angled with respect to the vertical axis indicative of the default or 
"unpinned" mode of operation such that selection of a given patient from panel list 
315 results in removal of the panel list in subsequent displays (see Figure 3C). Mode 
activation/deactivation can be toggled by subsequent selections of Pin icon 319d. 

Figure 3B provides an exemplary illustration of the pinning 
functionality of the present invention for maintaining the first window display 310 
containing the list of patients associated with the selected care unit while enabling 
display of different medical information in the second window 320 in response to user 
navigation between different applications. Referring now to Figure 3B in conjunction 
with Figure 3 A, a user first selects pin icon 319d to enable the pin functionality for 
maintaining list 315. A particular patient 3151 is then selected from the list of 
patients within the selected care unit 301. The user further selects application tabs 
such as Notes tab 3204 and Diagnosis sub-tab 32041 to launch the Notes->diagnosis 
application for retrieving from the data base diagnostic information associated with 
the selected patient 3151 according to predetermined search criteria and displaying 
the results in window portion 320. At the same time, window portion 310 maintains 
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5 the user-selectable list 315 of patients within the selected group or care unit 301. The 
resultant display is shown in Figure 3B. Subsequent selection of a different patient 
3153 within the given care unit causes that newly selected patient's data to be 
retrieved and loaded within the currently selected application tab. This 
advantageously enables " electronic rounds" within an application with minimal user 
10 interaction. 

As a further example. Figure 6A provides a flow chart illustration for 
displaying laboratory test results data for each patient within a given care unit. This 
is accomphshed by pinning the panel listing 315 (step 610), selecting a given patient 
y, 15 3153 (step 620), selecting labs tab 3205 to view the labs result for that patient (steps 
630, 640, 650) and then selecting each of the patients or selected patients within the 
O list 315 (step 660). Figure 6B provides an exemplary illustration of the resultant 

screen display associated with the aforementioned process. Note that a user may also 
jy navigate between different applications while maintaining the patient listing. For 

=5 20 example, from the Notes->Diagnostic application displayed in Figure 3B, user 
l^j^ selection of the "Review" subtab 32042 causes execution of a data base query for 

Q retrieving information associated with this application. Display window 320 then 

p displays the different medical data associated with the selected patient corresponding 

'^"^ to the search and display criteria for the "Review" application. In similar fashion, 

25 selecting each of the tabs for demographics, ventilator, trends, summary and reports 
(see Figure 3B) displays additional patient specific medical information 
corresponding to each of those categories of data based on specified search criteria for 
display to the user in window portion 320, while maintaining display of the list 315 of 
patients within that group in window portion 310. 

30 

The system of the present invention also operates to store in memory the last 
selected care unit that was viewed for each login account. In an exemplary 
embodiment, a data item record corresponding to the last selected care unit is stored 
in the data base and associated with that particular user account (e.g. user login). This 
35 record is then checked upon logging into the system, so that the user associated with 
that login will be placed in the care unit last selected in the previous session. 
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In another aspect, the system of the present invention enables a user to track a 
patient from one care unit to another within the hospital or health care environment. 
For example, a patient admitted into a hospital may move between different care units 
during his stay (e.g. from emergency room (ER) to intensive care unit (ICU)). 
Through the various nodes on the network LAN (e.g. hospital intranet) each 
associated with a given care unit and bed number, network connectivity with each of 
the medical devices (i.e. monitors) associated with a patient enables automatic 
tracking of the patient within the network. In an exemplary embodiment, server side 
software includes a network name server having a unique ID associated with each 
node and monitor device operative to communicate information to the server to 
automatically associate a particular node with a given patient connected to a given 
monitor on the network LAN. A memory card or smart card insertable into a monitor 
device connected to the network LAN at a given node may be used to identify and 
transfer associated medical information for that patient to another node within the 
network. 

Figure 7 provides an exemplary illustration of the process for detecting, 
tracking and updating the location of a patient within the system. This is 
accomplished by first establishing communications with each of the devices on the 
network (step 710). Once communications are established, patient data are acquired 
and processed by server side communications software program (step 720). A check 
of each patients' records is made to determine whether a relocation flag or indicator 
associated with a particular patient is set (step 730). If no flag is set, the system 
operates to collate the patient data including the group ID associated with each patient 
and store in the data base (steps 770-780). If, however, the check reveals a set 
relocation flag, a server processor module submits a request to the sending node 
requesting information including the patient's unique ID that is now associated with 
the new node. The system operates to determine the new group ID associated with 
the patient at the new location (i.e. node), and updates the information within the 
system, including the setting of new variables and parameters associating the patient 
with the new group ID. Medical parameter data stored within the system for that 
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patient associated with the previous group ID is then transferred to associate with the 
new identifier (steps 750-780). In this manner patient information may be obtained 
and updated to associate the patient with a new care unit. For example, a server side 
software communications processor receives periodic (e.g. every 20 seconds) 
informational updates (e.g. via broadcast messages) from each of the nodes on the 
system. The informational update messages comprise certain status information 
associated with the location of a particular patient associated with a node. When a 
patient moves from a given care unit and bed to a new care unit (and bed), tracking 
and association of the patient with the new care unit and node occurs in the following 
manner. First, an internal association of the monitor unit at that node connected with 
the patient takes place so that the node ID is associated wi± the patient now located at 
that node. A software process resident at the node then broadcasts a message 
containing this information over the LAN where it is received by the server 20 and 
analyzed. The information includes header information such as IP_address, the 
unique ID associated with that node, and additional data including patient name, 
monitor equipment status (e.g. on-line, off-line, standby), and a relocation indicator 
comprising a transfer flag which may be a bit or series of bits set in a predetermined 
manner such that the receiving software processor will recognize as a patient transfer. 
This prompts the server side software to interrogate the particular node by sending a 
network message requesting the identifier associated with that transferred patient. 
Upon receiving a response from the node, the server software will then look in its 
database 25 of unique patient ID's to locate the prior position of the patient. Server 
software then updates it's records based on the new node and sets internal parameters 
and session variables in order to collect monitoring data associated with that patient at 
that new node. 

As previously mentioned with regard to Figure 3A, user selection of 
search option 301c from the care unit list 301 generates a menu displaying a list of 
fields from which a user can search the data base to obtain medical information. An 
exemplary illustration is depicted in Figure 8A. As shown therein, user selection of 
the search option 30 IC generates a pop-up menu panel 800 displayed to the user 
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5 prompting the user to enter a search string. Entry of the user-selected search string 
causes the search engine within database 25 to search and retrieve a listing of patients 
within the relational database having a certain field or fields containing text that 
matches the search string for display to the user. 

10 For example, the list of fields from which a user can search may include Last 

Name 8001, Patient ID 8002, Physician 8003, Diagnosis 8004, and Procedure 8005. 
Each of these fields is associated with particular medical information within the 
relational data base 25 such that when a user selects one of the fields and enters a 
search string, the user interface displays in window portion 310 a list 315 of all 
15 patients that match the user- specified criteria. As is understood, this list may span 
Q multiple care units and may be pinned by selection of pin icon 319d to maintain this 

~ display while navigating through various applications via the application tabs. For 

^ example, selecting the "Physician" field 8003 and entering the text string "smith" 

^~ causes generation of a data base query executed by the search engine resident on 

, 20 server 20 for patients whose primary physician's last name includes the term 
" smith" . As shown in Figure SB, and in similar fashion to that depicted in Figure 5, 
a listing 315 of patients is returned in display window 310 along with associated 
medical information in window 320, corresponding to the system operative in board 
view mode (icon 319b). The user may then select each patient and navigate through 
25 the particular medical information available by means of the application tabs or icons 
to view desired data for that patient as previously discussed. As an example. Figure 
8C shows the results displayed to the user when a given patient 3153 is selected from 
the list 315 shown in Figure 8B. That is, selection of a given patient causes 
application window 320 to execute a search and display the results of the Summary 
30 application tab 3202. The user may further navigate through additional medical data 
associated with the patient by means of additional patient selection, application 
selection, or care unit selection to obtain desired medical data. 

In a further aspect, the search field 301c may include a further user selection 
35 8010 (Figure 8A) to enable a user to generate a "customized" care unit based on a 
user-specified criteria. For example, as shown in Figure 8A entry of the term 



2000P09139US01 



18 

"Smith" in the "Physician" field and selection of the "customize" function 8010 
causes the user interface display generator to store the user-assisted query on the 
system server associated with the given name to be retrieved and executed upon 
subsequent selection of the care label field 301 "Customize" search. If selected, the 
search criteria is stored in a session variable such that, even after a user logs off, a 
subsequent login and selection of the "customize" feature from the care unit list 
causes the software to invoke the customized query. This would enable a doctor, for 
example to obtain a list of her patients every time she logs in to the system. 

It is to be understood that the embodiments and variations shown and 
described herein are for illustrations only and that various modifications may be 
implemented by those skilled in the art without departing from the scope of the 
invention. 



